Remarks 

Status of application 

Claims 1-1 1 and 13-59 were examined and stand finally rejected in view of prior 

art. The claims have been amended to more clearly distinguish Applicant's invention 

from the prior art. In view of the amendments to the claims and the below remarks, 

reexamination and reconsideration are respectfully requested. 

The invention 

Applicant's invention enables users to collect and extract content from a number 
of different sources in a manner which provides real-time, interactive (i.e., user driven) 
content aggregation. Applicant's invention enables a user to collect various types of 
content components from a number of different sources (e.g., Web sites available via the 
Internet). The user can then create interactive messaging portlets using the collected 
components. An advantage of the architecture of Applicant's invention is that inter- 
portlet communication among messaging portlets on a given computer is handled locally 
without requiring interaction with a remote computer. This re 

Applicant's invention includes an innovative user interface, a web application 
"wizard" and other tools that make it easy for users to select and collect content and use 
the collected components create and implement messaging portlets. Applicant's 
invention includes a wizard (tool) that enables a user to select a message action (from a 
plurality of such actions which are available) and map the selected message action to a 
particular portlets (or portlet components) to create a messaging portlet. A user without 
extensive technical skills or training can use Applicant's invention to identify, extract, 
retrieve, and use content in situations that previously required complex development 
tasks by skilled programmers. 

General 

A. Claim Objection 

The Examiner has objected to Claim 50 on the basis that the limitation "said at 
least one collaborative element" lacks sufficient antecedent basis. Applicant has 
amended claim 50 as suggested by the Examiner, thereby overcoming the objection. 
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Prior art rejections 

A. Section 102 rejection: Jerrard-Dunne 

Claims 1-4, 9, 13, 14, 17-25, 30, 33-35, 38-44, 48, 51, 52, and 54-59 stand 
rejected under 35 U.S.C. 102(e) as being anticipated by US PGPub 2004/0090969 to 
Jerrard-Dunne et al (hereinafter "Jerrard-Dunne"). The Examiner's rejection of 
Applicant's Claim 1 as follows is representative of the rejection of Applicant's claims as 
anticipated by Jerrard-Dunne: 

Referring to claim 1, Jerrard-Dunne discloses a method for interactive content 
retrieval and display at a computer [user system 26] connected to a network 
[network 30] and having Internet access (see Fig 1 and [0020]), the method 
comprising: 

providing a plurality of portlets [for example, portlets 48 A-E] selected by a user 
[user 32 or portlet developer] from a plurality of sources [content provider system 
28] available via the Internet for retrieval of content for display (see [0026], lines 
8-14; [0030]; [0036], lines 1-7) in a user interface of the computer [user system 
26]; 

in response to user input, mapping a message action to a first portlet to create a 
messaging portlet [the developer links desired fields together using a user 
interface] (see [003 1]) for sending a message to a registrar [broker system 42] in 
response to user interaction with the messaging portlet [source portlet] (see 
[0036]-[0037] - when data is entered in the input field of the source portlet, the 
data is sent to the broker system); 

creating a listener portlet [destination portlet] by registering a second portlet [e.g., 
weather] selected by the user [developer] with the registrar [broker system 42] to 
receive messages from the messaging portlet [source portlet] (see [0032] and 
[0037], lines 6-10); 

in response to user interaction with the messaging portlet [a user 32 interacts with 
portlet data sharing system 10 through user system 26] (see [0025], lines 1-2 and 
[0036], lines 1-7), retrieving particular content for display in the user interface 
[content is displayed in the portal page] (see [0028]) based on the message 
received by the listener portlet [destination portlet] from the messaging portlet 
[source portlet] (see [0033], lines 22-25; [0036]; and [0037]); and 
displaying the particular content in the user interface [content is displayed in the 
portal page] (see [0028]). 

Under Section 102, a claim is anticipated only if each and every element as set 
forth in the claim is found, either expressly or inherently described, in the single prior art 
reference. (See, e.g., MPEP Section 2131.) As will be shown below, Jerrard-Dunne fails 
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to teach each and every element set forth in Apphcant's claims 1-4, 9, 13, 14, 17-25, 30, 
33-35, 38-44, 48, 51, 52, and 54-59 (as well as other claims), and therefore fails to 
establish anticipation of the claimed invention under Section 102. 

One significant difference between Applicant's invention and that of Jerrard- 
Dunne is that in Applicant's invention the messaging (broadcasting) component, the 
registrar, and the Hstener all reside within a user's web browser at a computing device 
(Applicant's specification, paragraphs [0095] - [0096]; Fig. 4). This is specifically 
described, for example, at paragraph [0097] of Applicant's specification as follows: 

Inter-portlet messaging is handled by the browser without requiring Web 
application host interaction . 

(Applicant's specification, paragraph [0097], emphasis added) 

Although Applicant's messaging portlets may retrieve content from a remote web 
server (e.g., as shown at Applicant's Fig. 4), all of the inter-portlet communication takes 
place within the web browser at the computer. This has several benefits. One benefit is 
that Applicant's approach reduces the amount of Internet bandwidth needed to deliver 
compound web applications. Another benefit of having all of the inter-portlet 
communications within the browser is that the user experience will be "faster" without 
trips to a backend component located on a remote computer (e.g., Web server). 

In contrast to Applicant's approach, Jerrard-Dunne's system relies on use of 
server-side components. As shown at Fig. 1 of Jerrard-Dunne, the portlet 48 runs at a 
user system 26, while the mapping system 38, creation system 40, broker system 42, and 
conversion system 44 all reside on a separate computer system (web server) 12 (Jerrard- 
Dunne, Fig. 1). This is described at paragraph [0020] of Jerrard-Dunne as follows: 

User system 26 and content provider system 28 are shown in communication with 
computer system 12 by interfacing with one or more I/O devices 22 of computer 
system 12 via a network 30 (e.g., LAN, WAN, Internet, etc.).... computer system 
12 represents any type of computerized system for providing access to a web site 
(e.g., a web server), user system 26 represents any type of computerized system 
that can be used to access the world wide web (e.g., a mobile phone, a handheld 
computer, a personal digital assistant, a portable (laptop) computer, a desktop 
computer, a workstation, a mainframe computer etc.), and content provider 
system 28 represents any type of computerized system for providing data to other 
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systems. 

(Jerrard-Dunne, paragraph [0020]). 

The Examiner equates the broker component of Jerrard-Dunne' s system with the 
registrar of Applicant's invention. However, as discussed above, in Jerrard-Dunne' s 
system, the broker component is a server-side component located on web server while the 
registrar of Applicant's invention is located in the browser on the client. In addition, 
Jerrard-Dunne describes inter-portlet communication as follows: 

...when a data value of a source field is modified, the "source" portlet sends a 
message to broker system 42. Broker system 42 accesses the mappings defined 
for the source field using mapping system 38, and sends a message to each 
"destination" portlet having a destination field with which the source field is 
shared. The message includes an identification of the destination field, and the 
updated data value for the destination field. When necessary, broker system 42 
can use conversion system 44 to convert the data between the source field and 
destination field data types. 

(Jerrard-Dunne, paragraph [0037]) 

Thus, J errard-Dunne's system relies on server-side components for implementin g 
inter-portlet messaging so that communications and data type conversion can be 
performed without requiring additional functionality in the portlets (Jerrard-Dunne, 
paragraph [0038]). This is not Applicant's approach. Applicant's approach provides for 
adding the registrar and other components inside the browser window at the client 
computer for implementation of inter-portlet messaging (Applicant's specification, 
paragraph [0105]; Fig. 5A-B). Rather than relying on server-side components for 
messaging and conversion of data types. Applicant's invention provides for adding 
functionality to the portlets and adding the registrar at the client computer. In Applicant's 
system the registrar is located in the browser window on the client computer and all 
messaging is handled within the browser (Applicant's specification, paragraphs [0095] - 
[0096]). Applicant's independent claims have been amended to more clearly articulate 
this distinction. For example. Applicant's claim 1, as amended, includes the following 
claim limitations: 



A method for interactive content retrieval and display at a computer connected to 



a network and having Internet access , the method comprising: 
providing a plurality of portlets selected by a user from a plurality of sources 
available via the Internet for retrieval of content for display in a user interface of 
the computer : 

in response to user input at the computer , defining a particular message action to 
be taken in response to user interaction with a first portlet, mapping the particular 
message action to the first portlet to create a messaging portlet for sending a 
message to a registrar in response to user interaction with the messaging portlet; 
wherein said registrar is located in a browser at the computer : 

(Applicant's claim 1, as amended, emphasis added) 

Applicant's system also serves a different role from the system of Jerrard-Dunne 
in that Applicant's system enables a user to collect content from a variety of different 
sources and technologies and use this content to create a simple web based browser 
application which includes interactive messaging portlets (Applicant's specification, 
paragraph [0093]). With Applicant's invention, the user may select (or collect) different 
types of content to be displayed and combine them together (e.g., on a web page). The 
user may then add message actions using a "mElement" wizard (web application tool) 
provided by Applicant's invention (Applicant's specification, paragraphs [0162] - [0164]). 
In this manner. Applicant's invention enables an end user to select and create their own 
web applications. Using Applicant's invention, a user with little or no programming or 
web design experience can combine content and produce an interactive web application 
using this web application tool (Applicant's specification, paragraph [0091]). These 
elements of a user selecting content and adding messages action to create messaging 
portlets which interact to create an interactive web application on the user's computer are 
specifically described in Applicant's claims, including, for instance, the limitations of 
claim 1 set forth above. 

In contrast, the user of the system of Jerrard-Dunne interacts with an application 
that has been previously created by a developer (Jerrard-Dunne, Fig. 1). With Jerrard- 
Dunne' s system, a portlet developer specifies data fields as an input field, an output field, 
an internal field or an input/output field and defines a data type for each field (Jerrard- 
Dunne, paragraph [0029]). Only some of the fields can share data with other fields. For 
example, input fields can only receive data from another portlet, while output fields can 
only send data to another portlet. Internal fields can not share data. With this approach. 
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the portlet developer must decides in advance which of the portlets may send and 
received messages to each other. The portlet developer is also responsible for placing the 
portlets on the page, adjusting the display properties of each portlet including font, color, 
size, location, content, form, and so forth (Jerrard-Dunne, paragraph [0030]). Thus, with 
the system of Jerrard-Dunne, an end user's abiHty to create or customize pages of 
interactive portlets (e.g., for use on his or her own computer) is constrained by 
development choices previously made by the developer. 

Applicant's invention also allows the user to use several different messaging 
actions or strategies for inter-portlet messaging. In creating a messaging portlet, a user 
can select from a plurality of messaging actions or strategies using the wizard (tool) 
provided by Applicant's invention (Applicant's specification, paragraph [0164]. Different 
messaging actions or strategies can be used based on the type of object (e.g., anchor 
objects, grid objects, form objects, database objects and custom objects) and the message 
action desired (Applicant's specification, paragraphs [0164] - [0170]). These limitations 
are also included in Applicant's amended claims. For example, claim 1 includes the 
following limitations: 

in response to user input at the computer, defining a particular message action to 
be taken in response to user interaction with a first portlet. mapping the particular 
message action to the first portlet to create a messaging portlet for sending a 
message to a registrar in response to user interaction with the messaging portlet; 
wherein said registrar is located in a browser at the computer; 

(Applicant's claim 1, as amended, emphasis added) 

Applicant's review of the Jerrard-Dunne reference, finds no similar feature which 
enables a user to define different messaging actions or strategies to be used for different 
objects of a given portlet. Although Jerrard-Dunne' s system includes a creafion module 
of some sort, it does not include the specific features of the wizard (tool) of Applicant's 
invention which enables a user to select portlets, define various types of message actions 
to be associated with particular portlets (or components thereof), and map the defined 
message action to the portlets to create messaging portlets in the manner described in 
Applicant's specification and claims. In addition, Jerrard-Dunne' s system relies on server 
side components for inter-portlet messaging and data type conversion, while Applicant's 
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solution provides for handling all inter-portlet communication locally on the client 
computer. Therefore, as Jerrard-Dunne does not teach or suggest all of the claim 
limitations of Applicant's claims Claims 1-4, 9, 13, 14, 17-25, 30, 33-35, 38-44, 48, 51, 
52, and 54-59 (and other claims) it is respectfully submitted that the claims distinguish 
over this reference and overcome any rejection under Section 102. 

B. Section 103(a) rejection: Jerrard-Dunne in view of Admitted Prior Art 

The Examiner has rejected claims 5, 6, 26, 27 and 45 under 35 U.S.C. 103(a) as 
being unpatentable over US PGPub 2004/0090969 to Jerrard-Dunne et al as applied 
respectively to claims 4, 25 and 42 above, further in view of Applicant's Admitted Prior 
Art (hereafter AAPA). 

The Examiner relies on Jerrard-Dunne as substantially teaching the claimed 
invention (as per the Examiner's rejection under Section 102 above), but acknowledges 
that Jerrard-Dunne fails to explicitly disclose the limitation of implementing the web 
page is implemented using a markup language. The Examiner states that it would have 
been obvious to one of ordinary skill in the art to implement the web page of Jerrard- 
Dunne using a markup language as disclosed by Applicant's admitted prior art. 

As to these claims. Applicant believes that the claims are allowable for at least the 
reasons cited above (as to the Section 102 rejection) pertaining to the deficiencies of 
Jerrard-Dunne as to Applicant's invention. Although Applicant admits that the use of a 
markup language for implementing a web page is known in the art, this does not cure any 
of the above-described deficiencies of the primary Jerrard-Dunne reference as to 
Applicant's invention. Accordingly, as the prior art reference(s), even when combined, 
fail to teach or suggest all the claim limitations, it is respectfully submitted that 
Applicant's claimed invention as set forth by these claims is distinguishable over the 
combined references, and that the rejection under Section 103 is overcome. 

C. Section 103(a) rejection: Jerrard-Dunne in view of Goldberg 

The Examiner has rejected claims 7, 8, 10, 11, 15, 16, 28, 29, 31, 32, 36, 37, 46, 
47, 49, 50 and 53 under 35 U.S.C. 103(a) as being unpatentable over US PGPub 
2004/0090969 to Jerrard-Dunne et al as applied respectively to claims 1, 22 and 42 
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above, further in view of US PGPub 2004/0199541 to Goldberg et al (hereinafter 
"Goldberg"). Here, the Examiner relies again on Jerrard-Dunne as substantially teaching 
Applicant's claimed invention, but acknowledges that Jerrard-Dunne fails to disclose 
various limitations of these dependent claims, including that the messaging portlet is 
structured as an HTML inline frame. The Examiner adds Goldberg for each of the 
referenced teachings and states that it would have been obvious to one of ordinary skill in 
the art to use Goldberg's features with those of Jerrard-Dunne. 

Applicant's claims are believed to be allowable for at least the reasons cited above 
(as to the Section 102 rejection) pertaining to the deficiencies of Jerrard-Dunne as to 
Applicant's invention. As these claims are dependent upon, and incorporate the 
limitations of Applicant's independent claims, they are distinguishable for the reasons 
described in detail. As Goldberg does not provide any teaching of messaging portlets 
that cures any of these deficiencies of Jerrard-Dunne. Goldberg discusses use of 
IFRAME technology that allows individual items on a web page to be updated without a 
full-page refresh cursor commit (Goldberg, paragraph [0053]). However, Goldberg 
makes no mention whatsoever of messaging portlets or of using IFRAME technology for 
implementing messaging portlets. Instead, the messaging described in Goldberg is 
sending an electronic mail message of a browser-based user interface to users so as to 
communicate business information to such users (Goldberg, Abstract). Moreover, and as 
discussed above, Jerrard-Dunne specifically teaches the use of server-side components 
for messaging and data type conversion rather than adding this fiinctionality in the 
portlets (Jerrard-Dunne, paragraph [0038]). Thus, Jerrard-Dunne "teaches away" from 
the idea of adding this flmctionality to the portlets, whether the fiinctionality is 
implemented using HTML inline frames or otherwise. 

Thus, as the Jerrard-Dunne reference, even when combined with Goldberg, does 
not teach or suggest all the claim limitations, it is respectfiiUy submitted that Applicant's 
claimed invention is distinguishable over these references, and that the rejection under 
Section 103 is overcome. 

Any dependent claims not explicitly discussed are believed to be allowable by 
virtue of dependency from Applicant's independent claims, as discussed in detail above. 
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Conclusion 

In view of the foregoing remarks and the amendment to the claims, it is believed 
that all claims are now in condition for allowance. Hence, it is respectfully requested that 
the application be passed to issue at an early date. 

If for any reason the Examiner feels that a telephone conference would in any way 
expedite prosecution of the subject application, the Examiner is invited to telephone the 
undersigned at 925 465 0361. 

Respectfully submitted. 

Date: March 9, 2007 /G. Mack Riddle/ 

G. Mack Riddle; Reg. No. 55,572 
Attorney of Record 

925 465 0361 
925 465 8134 FAX 
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